Text message authentication system

ABSTRACT

Systems and method for authenticating users are presented. A system can send a passkey to a user interface of a known device. A user can then send a messaging service message with the passkey from a second device to the system. After receiving the message from the user, the system can extract the passkey from the message, and compare the received passkey against the passkey originally sent to the user. The known device and the second device can each have separate and unique device identifiers.

This application is a divisional of U.S. patent application Ser. No.13/548,640 filed on Jul. 13, 2012 and claims the benefit of U.S.Provisional Patent Application No. 61/524,676 filed on Aug. 17, 2011.This and all other extrinsic materials discussed herein are incorporatedby reference in their entirety. Where a definition or use of a term inan incorporated reference is inconsistent or contrary to the definitionof that term provided herein, the definition of that term providedherein applies and the definition of that term in the reference does notapply.

FIELD OF THE INVENTION

The field of the intention is text message authentication systems.

BACKGROUND

Improving the security of online and other remote transactions is veryimportant to limit access to authorized personnel, for example whenaccessing high-security documents or when purchasing an item with abusiness or personal account. Both parties in any such transaction needto be certain that only authorized personnel can participate in such atransaction to prevent identity theft or improper actions. While it isknown to use a username/password to authenticate a remote user,passwords can be inferred or stolen from authorized personnel and usedto subsume the identity of an authorized personnel.

U.S. Pat. No. 6,880,079 to Kefford discusses a method for sending amessage to a trusted recipient by sending an encrypted reply to a mobiledevice. The trusted recipient who wishes to read the reply must firsthave control of the mobile device, and must also have a key to decryptthe encrypted reply. Kefford, however, does not appear to allow thesystem to verify the trusted recipient.

U.S. pat. publ. no. 2009/0235339 to Mennes et al. (publ. September 2009)teaches a method of authenticating a trusted recipient by providing arecipient with a one-time security token through a trusted device thatthe trusted recipient must use in order to gain access to the system.However, Mennes fails to consider a situation where the trusted deviceitself has been stolen or otherwise compromised.

These systems can also be problematic where an unauthorized user stealsand attempts to use a user's mobile device to send and receive repliesfrom the system. In such circumstances, the systems fail to protect theuser even though the responses are encrypted. In addition, the use ofsecurity tokens has myriad problems where an unauthorized user cansimply steal the user's security to gain access to the system.

Therefore, there remains a need for improved systems and methods forverifying an identity of a trusted user prior to a transaction using amessage authentication system.

SUMMARY OF THE INVENTION

The inventive subject matter provides apparatus, systems and methods inwhich a system authenticates a user by sending or receiving identifyingcodes or other information from a device, user interface, or other meansof communication.

Preferred systems are configured to authenticate a user by sending afirst passkey to a user interface of a known device having an associateddevice identifier. The passkey can be sent through a first securecommunication pathway. Upon receipt, the user can send or otherwisesubmit the same passkey through a second communication pathway to thesystem from a second device with an associated device identifier that ispreferably different from the device identifier associated with theother device. The system can then compare the first passkey against thereceived second passkey, and the first device identifier against thesecond device identifier, to thereby authenticate the user.

In another aspect of the inventive subject matter, it is contemplatedthat the system can authenticate a user based on the most recent requestfor a passkey rather than a previous request. After the system receivesa subsequent request for a passkey, the system can send a second passkeyto the user interface over a network. After the system receives amessage from the user via the user's second device, the system thencompares the passkey in the received message against the passkey sent tothe user.

An exemplary embodiment of the invention can be found in TextPower'sTextKey™ product, which was awarded the “Best IntrusionDetection/Prevention Solution” of 2011. This honor was voted on by apanel of government, military, and website security experts convened byGovernment Security News magazine. TextPower's TextKey™ product was alsonamed the “Best Authentication Solution” in the Info Security ProductsGuide 2012 Global Excellence Awards competition.

Various objects, features, aspects and advantages of the inventivesubject matter will become more apparent from the following detaileddescription of preferred embodiments, along with the accompanyingdrawing figures in which like numerals represent like components.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a schematic of an embodiment of a system for authenticating auser.

FIG. 2A is an embodiment of a passkey that a user has entered as amessage on a device.

FIG. 2B is an embodiment of a passkey along with a signature that a userhas entered as a message on a device.

DETAILED DESCRIPTION

It should be noted that while the following description is drawn to acomputer/server based authentication system, various alternativeconfigurations are also deemed suitable and may employ various computingdevices including servers, interfaces, systems, databases, agents,peers, engines, controllers, or other types of computing devicesoperating individually or collectively. One should appreciate thecomputing devices comprise a processor configured to execute softwareinstructions stored on a tangible, non-transitory computer readablestorage medium (e.g., hard drive, solid state drive, RAM, flash, ROM,etc.). The software instructions preferably configure the computingdevice to provide the roles, responsibilities, or other functionality asdiscussed below with respect to the disclosed apparatus. In especiallypreferred embodiments, the various servers, systems, databases, orinterfaces exchange data using standardized protocols or algorithms,possibly based on HTTP, HTTPS, AES, public-private key exchanges, webservice APIs, known financial transaction protocols, or other electronicinformation exchanging methods. Data exchanges preferably are conductedover a packet-switched network, the Internet, LAN, WAN, VPN, or othertype of packet switched network.

The following discussion provides many example embodiments of theinventive subject matter. Although each embodiment represents a singlecombination of inventive elements, the inventive subject matter isconsidered to include all possible combinations of the disclosedelements. Thus if one embodiment comprises elements A, B, and C, and asecond embodiment comprises elements B and D, then the inventive subjectmatter is also considered to include other remaining combinations of A,B, C, or D, even if not explicitly disclosed.

FIG. 1 illustrates an embodiment of a system 100 configured toauthenticate a user. Generally, a computer system 110 first sends theuser a passkey through a known secure channel 102, such as a securedwebsite that can only be accessed through a website passkey. A usercould access the secure channel 102 through a terminal or computersystem 120, for example, which accesses computer system 110 having auser database 112. The terminal or computer system 120 could include auser interface. Preferably, the user gains access to the system 100 bysome sort of authentication mechanism, such as a username/passwordauthentication mechanism. User database 112 preferably has a list ofusers each of which is associated with one or more device identifiersthat act as “keyholes” for the present system. In the embodiment shownin FIG. 1, the user database 112 comprises a device identifier for thefirst device, i.e., the terminal or computer system 120.

As used herein, a “passkey” is any object designated by a user which canbe used to authenticate the user's identity, such as an alphanumericword or phrase, an image selected or created by a user, a biometricsignature (i.e. fingerprint, iris/retina scan, voiceprint, or chemicalsecretion), or a physical key. As used herein, a “communication pathway”is any method of communication, whether it be oral, tactile, electrical,or through other means. Preferably the passkey is configured to betransmitted through an electrical communication pathway, such as a wiredor wireless network, so that the passkey could be easily manipulated bya computer system.

The computer system 110 can also be configured to communicate with asecond device 130, which could be a mobile phone or other computingsystem. Where the second device 130 comprises a mobile phone, it iscontemplated that the phone's unique phone number or numbers could beused as a device identifier associated with the second device 130.However, the second device 130 could be any device having a unique orsemi-unique device identifier without departing from the scope of theinvention. Contemplated devices include, for example, desktop orportable computers with unique network cards or serial numbers includinglaptops, tablet PCs, netbooks and so forth, mobile and smart telephones,key FOBs with UIDs associated with the device, and devices having aunique signature of a user, such as a social security number or emailaddress.

The system 100 can be configured to authenticate the user at terminal120 by sending a passkey 122 to the user through terminal 120. The userthen enters the passkey 122 into a separate device 130 (e.g., mobilephone) and sends the passkey as a message to the system 110 throughnetwork access point 140. Preferably, the passkey is sent such that thesystem 110 can trace the message to ensure that the message came from adevice having at least one of the device identifier(s) associated withthe user. In an exemplary embodiment, the passkey is sent via amessaging service message, such as a SMS, SMIL, or an MMS protocol,which embeds the device identifier, typically the device's phone number,with the message. However, any commercially suitable protocol or servicecould be used to transmit the message to system 110.

After receiving the message from device 130, system 110 can then dissectthe messaging service message to identify the sent passkey from thesecond device 130 as well as the sent device identifier associated withthe second device 130. The system 110 could then compare the passkeysent from the device 130 against the initial passkey 122 sent to theterminal 120 or other computing device, and could also be configured tocompare the device identifier sent from the device 130 against thedevice identifier associated with the user in the user database 112 toauthenticate the user.

In this manner, the system 110 can authenticate a user accessing thesystem 110 via terminal 120 in a unique, novel way by forcing the userto send a passkey through a known, authenticated device 130 thatpreferably does not leave the user's person. Any counterfeit user whowishes to spoof another user's identity would not only need to know theother user's username/password, but would also need to steal theauthenticated device from the user.

In a simple embodiment, the passkey could be an alphanumeric phrase,such as a password that a user enters into a phone or other device suchas by using a keyboard. However, the passkey could alternativelycomprise an audio phrase that needs to be uttered by the user or couldcomprise a drawing. Other contemplated passkeys could comprise abiometric signature, a random-generated number based on a predefined setof algorithms, an answer to a question, and any other commerciallysuitable authentication schemes or combination(s) thereof. In apreferred embodiment, the user adds a separate signature passkey to thepasskey 122 that is sent to the user via terminal 120. For example, asshown in FIG. 2A, the user sends passkey 122 as an SMS message, but inFIG. 2B, the user sends passkey 122 along with signature 210 as an SMSmessage, adding yet another level of authentication. In the case of anaudio message or a drawing, a user could utter the audio message insteadof copying or otherwise recording the audio message, which adds a voicesignature to the message. Or a user could add a written signature to themessaging service message, which could then be compared to the user'sknown signature using various known methods.

The specific device identifier will likely depend on the user's device,and contemplated device identifiers including, for example, a telephonenumber, an internet protocol (IP) address, a MAC address, an emailaddress, a device's serial number, a Unique Device Identifier (UDID) orother device signature, or other unique identifier.

Using the device identifier, the device of a user can be identified,defined, or otherwise assigned a device identifier from registrationinformation submitted by the user or from any other commerciallysuitable means of identifying the device. For example, where the useruses the specific device during the registration process or otherwisecommunicates with system 110, it is contemplated that the deviceidentifier can be automatically obtained from the user's device duringthe registration process. This device identifier can then be stored inthe database 112 or other storage device.

In still other embodiments, the first passkey 122 (e.g. alphanumericphrase, etc.) and the first device identifier (e.g. telephone number,email address, etc.) can be coupled or otherwise associated before thesystem 110 sends the first passkey 122 to the user interface 120. In yetother embodiments, the system 110 can send the first passkey 122 afterthe user enters a user name and password. It is contemplated that thesystem 110 can send the passkey through any suitable messaging services.

All intranet and internet network configurations are contemplated toperform the comparison of the passkeys and device identifiers includinga remote server or service, a local server, a local server coupled to adatabase, a user interface implemented on a remote client connected to alocal server, and others.

The service could be implemented as part of a company's security, suchas a module that is installed on a local server, or the service could beimplemented on a remote computer system (not shown) with which system110 is configured to interface. In such an environment, the local servercould send a command to the remote computer system to authenticate theuser on terminal 120. The remote server could then send a passkey to theuser, could receive the messaging service message after the user sendsthe passkey from the user's device and optionally extract a user-enteredpassword from the message, could verify the user's device identifier andpassword, and then could send either (a) an authorization code to thelocal server, informing the local server that the user has beenauthenticated, or (b) an alarm to the local server, informing the localserver that the user has not been authenticated.

All suitable telephony and telecommunications devices are contemplatedincluding a cellular enabled device, a mobile telephone, a satellitephone, a mobile tablet device, a cloud computing station, a laptop,desktop, or others. All suitable messaging services are contemplated,including for example, SMS, SMIL, MMS, EMS, email services, instantmessaging, and others.

All messages, notifications, and alerts are contemplated includingsending an alert when the comparing step fails, sending privateinformation through the user interface when the comparing step succeeds,sending an authorization code to a remote server when the comparing stepsucceeds, sending an authorization code in response to a ping, sendingan alarm when the comparing step is performed after a threshold periodof time, and others.

In an exemplary embodiment, the passkey 122 could expire after a certainthreshold period of time, such that if a user sends the messagingservice message after the threshold period of time, such as 2 minutes, 5minutes, 10 minutes, or 30 minutes, then the user would remainnon-authenticated. The passkey could also expire for other reasons, suchas if the user inputs the wrong passkey, or if the user requests asecond, replacement passkey.

System 110 can be further configured to avoid conflicting or multiplerequests for passkeys. For example, the system 110 may receive a requestfor a third passkey before it receives the messaging service messagewith a passkey from the second device 130. Based on the request, thesystem 110 can send the third passkey and then compare this passkeyagainst the passkey from the second device 130 to authenticate the user.After comparing these passkeys, the system 110 can send an authorizationcode to a remote server if the comparison is successful. The system 110can also send an alert if the comparison of the old first passkeyagainst the second passkey succeeds.

In another embodiment, the user can send encrypted information to thesystem 110 by entering the information into a web-based application thatcan be accessed from a computer terminal (e.g. 120), mobile device,mobile phone, tablet, or other computing system. The web-basedapplication encrypts the message and provides a secure connectionbetween the user's device and the system 110. The user can also select arecipient from their address book or the user can enter the recipient'sphone number manually within the web-based application.

Once the system 110 receives the encrypted message, the system 110 canstore the message on the server. The system can then produce a textmessage in plain, non-encrypted format and send this text message to theintended recipient who has a device, for example a mobile device 130.The text message can include a URL that the intended recipient can clickor tap on from their mobile device to access a webpage on their mobilebrowser.

Upon reaching the web page, the intended recipient must enter a passwordto decrypt and read the message stored on the system server. It iscontemplated that the password used to decrypt and access the storedmessage can be defined by the user upon registration, in order to verifyownership of the mobile phone used. It is further contemplated that thesender of the message can assign a password that can be used by a listof recipients. The recipients can know the password in advance or learnthe password through other methods, for example, email, phone, and otherforms of communication.

Once the recipient enters the password, the decrypted message isdisplayed on their mobile browser on their smart phone (e.g. 130),tablet, or other mobile device. The recipient can choose to delete themessage, or the recipient can choose to store the message. The user canalso define parameters wherein the system automatically deletes theencrypted message upon a predefined period of time, a set number ofreads, security breach, or other trigger.

As used herein, and unless the context dictates otherwise, the term“coupled to” is intended to include both direct coupling (in which twoelements that are coupled to each other contact each other) and indirectcoupling (in which at least one additional element is located betweenthe two elements). Therefore, the terms “coupled to” and “coupled with”are used synonymously.

Thus, specific compositions and methods of authenticating a user havebeen disclosed. It should be apparent to those skilled in the art thatmany more modifications besides those already described are possiblewithout departing from the inventive concepts herein. The inventivesubject matter, therefore, is not to be restricted except in the scopeof the appended claims. Moreover, in interpreting both the specificationand the claims, all terms should be interpreted in the broadest possiblemanner consistent with the context. In particular, the terms “comprises”and “comprising” should be interpreted as referring to elements,components, or steps in a non-exclusive manner, indicating that thereferenced elements, components, or steps may be present, or utilized,or combined with other elements, components, or steps that are notexpressly referenced. Where the specification claims refers to at leastone of something selected from the group consisting of A, B, C . . . .and N, the text should be interpreted as requiring only one element fromthe group, not A plus N, or B plus N, etc.

What is claimed is:
 1. A method of authenticating a user, using aservice, an initiating device, and an authenticating device, wherein theinitiating device is different than the authenticating device,comprising the following steps, in sequence: associating a device ID ofthe authenticating device with a user ID; and the service authenticatingthe user by: (a) receiving the user ID via the initiating device; (b)sending the user a one-time authentication code; and (c) receiving theone-time authentication code and the device ID.
 2. The method of claim1, further comprising using a telephone number to send one-timeauthentication code to the user.
 3. The method of claim 1, furthercomprising using an email address to send the one-time authenticationcode to the user.
 4. The method of claim 1, wherein the one-timeauthentication code comprises an alphanumeric phrase.
 5. The method ofclaim 1, wherein the one-time authentication code comprises an audiophrase.
 6. The method of claim 1, wherein the one-time authenticationcode comprises a drawing.
 7. The method of claim 1, wherein the serviceis distal to both the initiating device and the authenticating device.8. The method of claim 1, wherein the authenticating device comprises atelephony enabled device.
 9. The method of claim 1, wherein theauthenticating device comprises a cellular enabled device.
 10. Themethod of claim 1, wherein the authenticating device comprises a mobiletelephone.
 11. The method of claim 1, wherein the service sends theone-time authentication code via an SMS message.
 12. The method of claim1, wherein the service sends the one-time authentication code via anSMIL message.
 13. The method of claim 1, wherein the service sends theone-time authentication code via an MMS message.
 14. The method of claim1, further comprising sending an alert when the one-time authenticationcode received by the service does not match the one-time authenticationcode sent by the service.
 15. The method of claim 1, further comprisingsending an alert when the device ID received by the service does notmatch the device ID associated with the user ID received by the service.16. The method of claim 1, wherein the device ID of the authenticatingdevice comprises an internet protocol (IP) address.
 17. The method ofclaim 1, wherein the device ID of the authenticating device comprises aMAC address.
 18. The method of claim 1, wherein the device ID of theauthenticating device comprises a serial number.
 19. The method of claim1, wherein the device ID of the authenticating device comprises a UniqueDevice Identifier (UDID).